Programmable logic devices (PLDs) exist as a well-known type of integrated circuit (IC) that may be programmed by a user to perform specified logic functions. There are different types of programmable logic devices, such as programmable logic arrays (PLAs) and complex programmable logic devices (CPLDs). One type of programmable logic device, called a field programmable gate array (FPGA), is very popular because of a superior combination of capacity, flexibility, time-to-market, and cost.
An FPGA typically includes an array of configurable logic blocks (CLBs) surrounded by a ring of programmable input/output blocks (IOBs), and support circuitry such as digital clock managers (DCMs) having delay lock loops (DLLs). The CLBs and IOBs are interconnected by a programmable interconnect structure. The CLBs, IOBs, and interconnect structure are typically programmed by loading a stream of configuration data (bitstream) into internal configuration memory cells that define how the CLBs, IOBs, and interconnect structure are configured. The configuration bitstream may be read from an external memory, conventionally an external integrated circuit memory EEPROM, EPROM, PROM, and the like, though other types of memory may be used. The collective states of the individual memory cells then determine the function of the FPGA.
Conventionally, such a bitstream is generated from tools for implementing a design from at least one of a schematic capture of the design and a hardware description language (“HDL”) version of the design, such as verilog or Very High Speed Integrated Circuit (“VHSIC”) HDL (“VHDL”), to provide a textual description of circuitry (“text-circuit description”) that is synthesized and implemented. A more recent addition to HDL involves use of a programming language, such C/C++ as in SystemC from Synopsys of Mountain View, Calif., to generate a circuit design that may be synthesized and implemented.
Circuit synthesis is used in designing all types of complex integrated circuits. One use is for designing hardwired circuitry, such as in FPGAs, processors, Application Specific Standard Products (ASSPs), and the like. Another use is for designing Application Specific Integrated Circuits (ASICs), including ASIC standard cells, where a vendor or customer uses synthesis tools to programmatically configure logic built on such an integrated circuit. Another use of synthesis tools is programmatically configuring a portion of an FPGA to provide a design. For purposes of clarity, an FPGA integrated circuit is described, though it will be apparent that any integrated circuit of sufficient complexity designable with synthesis tools may be implemented.
Once a design is created and implemented (“hardware implementation”), for example for an FPGA, it may be tested. Testing is useful to ensure that a hardware implementation functions equivalently to an HDL or higher-level abstraction, from which such hardware implementation was derived, implemented on a computer with simulation tools (“computer implementation”). For example, known high-level software tools, such as SystemC, System Generator for DSP from Xilinx of San Jose, Calif., and MATLAB and Simulink from The MathWorks of Natick, Mass., among others, facilitate circuit design and simulation at higher-levels of abstraction than classical hardware design. Furthermore, software tools, such as SystemC and System Generator for DSP, among others, have design conversion capability to covert a design into a synthesizable text-circuit description.
A computer implementation is compared to a hardware implementation counterpart by providing like input stimulus to each and comparing test results. This may be done by co-simulation, or by comparing test results from a hardware implementation to “known good” results from a computer simulation. Conventionally, “known good” results or “golden vectors” (“target test results”) are obtained from a predetermined set of input test vectors. Thus, output test vectors, which may be compressed, from a hardware implementation are compared against target test results.
However, in contrast to computer simulations, hardware implementations conventionally have a clock stabilization problem, especially when multiple clock signals are derived from a single input clock source. For example, multiple clock signals generated from a single DLL may experience stabilization problems. In hardware implementations, there is an initial interval after startup when clocks may be unstable, and where related clock signals may not be phase aligned. After this initial interval, clocks conventionally stabilize and rising edges of related clocks are conventionally phase aligned to be within tolerance. However, because a computer simulation does not have clock constraints equivalent to those of a hardware implementation counterpart during a post-startup interval, there is ambiguity with respect to when to compare hardware implementation test results to target test results.
Accordingly, it would be both desirable and useful to provide means to identify when clock stabilization of a hardware implementation occurs to reduce ambiguity in comparing test results.